1. Field of the Invention
The present invention generally relates to data processing and more particularly to memory management in a logically partitioned environment.
2. Description of the Related Art
Logical partitioning refers to the ability to make a system run as if it were two or more independent systems. Each logical partition represents a division of resources in the system and operates as an independent logical system. Each partition is logical because the division of resources may be physical or virtual. An example of logical partitions is the partitioning of a multiprocessor computer system into multiple independent servers, each with its own processors, main storage and I/O devices. One of multiple different operating systems, such as AIX®, LINUX and others can be running in each partition. AIX® is a registered trademark of International Business Machines, Inc.
Logically partitioned systems include a software component referred to as a partition manager. The partition manager is responsible for managing the various logical partitions on the system. In order to perform its responsibilities, the partition manager must have sufficient memory available. In addition, some form of a preemptive memory management technique is needed to avoid arriving at some unknown point in an activation path before discovering that insufficient memory is allocated to the partition manager. Such a condition would require extensive ability to “undo” a partially accepted configuration change throughout the partition manager. Implementing such ability would involves central tracking of which components had already been initialized and which had not, as well as interfaces in all the components to deal with undoing the partially committed change a user has requested. In addition, the likelihood of a memory allocation failing during the activation path increases, which may expose a coding bug for not handling the failure.
One possibility to ensure sufficient memory is to “pre-allocate” memory. However, pre-allocation presents numerous challenges and undesirable consequences. In particular, pre-allocation would require extensive cross component interfaces between configuration management and every other component in the partition manager which allocates storage. New interfaces would also be necessitated between numerous other components to pipe pre-allocation messages around. In essence, the entire allocation code paths would have to be triplicated: pre-allocate, rollback-pre-allocated, and commit-pre-allocated. The pre-allocate code path allocates space for a given configuration change, but does not allow the system to act as if the change has been accepted. The rollback-pre-allocated code path returns the pre-allocated space to the system because the change is being discarded (most likely because of some component's failure to pre-allocate due to insufficient storage). The commit-pre-allocated code path accepts the change that caused the pre-allocate. In addition, all components which allocate memory would have to track the state of their allocations (i.e., non-allocated, pre-allocated and allocated), and participate in some form of multiphase commitment control, such as the above three phases. These changes would add considerable amounts of code to the partition manager, in addition to nontrivial code complexity to every component that allocates memory, as well as requiring additional space, since components would need to allocate structures in order to track the pre-allocation and allocation state of their allocations.
Therefore, there is a need for a system and method for managing memory in a partitioned environment.